學 Kubernetes 的第三十二天 - Autoscaling - 概論 - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天

2024 iThome 鐵人賽

Kubernetes

都什麼年代了，還在學 Kubernetes系列第 32 篇

學 Kubernetes 的第三十二天 - Autoscaling - 概論

16th鐵人賽 kubernetes k8s

vincentlin2447

團隊Grafana 科研遠征小隊

2024-10-16 04:31:11

161 瀏覽

分享至

在 Kubernetes 中，我們可以根據當前的資源需求擴展和縮減工作負載。這讓叢集可以更靈活、更高效地面對資源需求的變化。

擴縮工作負載大致上分為兩種方式，一種是增加或減少工作負載所管理的副本數量，或者就地調整副本的可用資源。

Kubernetes 也支援工作負載的自動擴縮，也就是本文要介紹的 Autoscaling。自動擴縮是一種根據應用程序的負載需求自動調整資源的機制。其大致分為以下策略:

Horizontal Pod Autoscaler (HPA)
Vertical Pod Autoscaler (VPA)
Cluster Autoscaler (CA)
Event-Driven Autoscaling (EDA)
Cluster Proportional Autoscaler (CPA)

讓我們來看看他們之間的差異以及原理。

Horizontal Pod Autoscaler (HPA)

HPA 是 Kubernetes 中的一個控制器。它根據 CPU 使用率或其他應用程序指標（如內存、HTTP 請求數量等）自動調整 Pod 的副本數量。

工作原理

HPA 監控指定的指標，並根據目標值計算需要調整的 Pod 數量。當指標超過或低於目標值時，HPA 會創建或刪除 Pod 以維持性能。

由於它是透過 Metrics Server 指標的方式實現，因此需要在叢集中安裝 Metrics Server ，HPA 才能正常運作。

適用場景

當應用程序負載變化較大時，例如高峰期和非高峰期的流量波動。
需要自動調整資源以應對突發流量的應用。

Vertical Pod Autoscaler (VPA)

我們可以想像一下，當我們部署應用時:

如果過度分配資源：會浪費未使用的資源，付出額外成本。
如果資源分配不足：資源將很快用完，應用程式效能將受到影響，並且 kubelet 可能會開始殺死 pod，直到資源利用率下降。

這些過程都會付出額外的金錢與時間成本，只依靠 HPA 並不能很好的解決這個問題。所以
Kubernetes 平台中提供的 Vertical Pod Autoscaler 功能，用於自動調整 Pod 的 CPU 和內存資源分配，以適應應用程序實際需求。

不同於 HPA 直接可以在叢集配置使用，VPA 並非 Kubernetes 的預設組件，而是一個獨立的項目。因此要使用它必需另外安裝。

工作原理

VPA 監控 Pod 的資源使用情況，並根據歷史數據和當前使用情況建議或自動調整 Pod 的資源限制和請求。

該專案包含 3 個元件：

Recommender：它會監控目前及過去的資源消耗，並據此提供容器的 CPU 及記憶體要求的建議值。
Updater：它會檢查哪些受管理的 Pod 設定了正確的資源，如果沒有，就會關閉它們，以便其控制器可以根據更新的請求重新建立它們。
Admission Plugin：它會在新的 Pod 上設定正確的資源請求（無論是剛建立的 Pod，或是因 Updater 的活動而由其控制器重新建立的 Pod）。

簡單來說，我們可以將 VPA 工作流程總結為：

觀察資源使用 → 推薦資源請求 → 更新資源

目前 VPA 的更新方式有以下選項:

Off：VPA 只會提供建議，不會自動變更資源需求。
Initial：VPA 只在 Pod 建立時指派資源需求，之後不會變更。
Recreate：VPA 會在 Pod 建立時指派資源要求，並透過驅逐和重新建立現有 Pod 來更新。
Auto：它會根據建議重新建立 Pod。

適用場景

當應用程序的資源需求隨時間變化，且手動調整資源繁瑣或不切實際時。
適合需要動態調整資源以優化成本和性能的工作負載。

Cluster Autoscaling (CA)

Cluster Autoscaler (CA) 是用於自動調整 Kubernetes 集群中節點數量的工具，根據集群中 Pod 的需求增減節點。

隨著新 Pod 的部署以及現有 Pod 的副本數量增加，叢集工作節點可能會用完所有分配的資源。因此，無法在現有工作節點上安排更多的 Pod。某些 Pod 可能會進入掛起 (pending) 狀態，等待 CPU 和內存，並可能造成中斷。如果身為 Kubernetes 管理員，可以透過向叢集新增更多工作節點以啟用額外 Pod 的調度來手動解決此問題。

除了手動擴展，Kubernetes Cluster Autoscaler 可以透過自動化容量管理來解決這個問題。具體來說，Cluster Autoscaler 可自動執行在 K8s 叢集中新增和刪除工作節點的過程。

工作原理

Cluster AutoScaler 會定期檢查節點和 Pod 的狀態，並根據節點使用率或 Pod 調度狀態採取操作。當 Cluster Autoscaler 偵測到叢集上待處理的 pod 時，它將新增更多節點，直到調度待處理的 pod 或叢集達到最大節點限制。如果節點利用率較低且 Pod 可以移動到其他節點，Cluster Autoscaler 將刪除額外的節點。

適用場景

當集群中的工作負載波動較大，需要根據需求動態增減節點。
適合需要節省成本並動態適應資源需求的場景。

支持平台

大多數雲端供應商支援叢集自動縮放，但本地自架 K8s 環境不支援它。叢集自動擴展是「僅限雲端」的功能，因為本地部署缺乏自動擴展程序所需的自動虛擬機器創建和刪除的 API。

這些 Kubernetes 平台支援 Cluster Autoscaler:

Google Kubernetes Engine (GKE)
Azure Kubernetes (AKS)
Elastic Kubernetes Service (EKS)
其他幾個不太流行的 K8s 雲端平台。

Event Driven Autoscaling (EDA)

Event Driven Autoscaling (EDA) 是一種 HPA 的延伸，通過不同方式提供指標或事件，驅動 HPA 基於這些指標或事件自動水平伸縮。Kubernetes 官方並沒有定義和實作 EDA 的概念，只能透過社區和第三方工具。由於沒有一個統一的規範，每個工具實現的方式都不一樣，因此資源無法完全通用。

比較有名的工具有:

KEDA (Kubernetes Event-Driven Autoscaling)： KEDA 是一個從 CNCF 畢業的開源項目，它比較專注支持多種列隊事件來源 (如 RabbitMQ、Kafka、AWS SQS、Azure Queue Storage 等)，這些來源作為指標觸發調整行動
Prometheus Adapter：Prometheus 也是 CNCF 畢業項目，是一套用於監控與警報的開源項目，可將即時的指標資料儲存到時間序列資料庫。Prometheus Adapter 允許 Kubernetes 使用Prometheus 的自定義指標來驅動 HPA，動態調整 Pod 的副本數量。

適用場景

需要基於特定事件或自定義指標進行擴展的應用。
對實時性要求較高的服務。

Cluster Proportional Autoscaler (CPA)

Cluster Proportional Autoscaler (CPA) 是一個 Kubernetes 組件，用於根據集群中的節點或 Pod 數量，自動調整其他系統組件（如 CoreDNS、Heapster、Metric Server 等）的副本數量，以確保這些組件在集群擴展或縮減時能夠提供足夠的資源和高可用性。

雖然隨著 Node 的增加，其他系統組件（如 CoreDNS）的副本數量會自動增加。但 Cluster Proportional Autoscaler 提供了更靈活和精細的控制。

優勢

精確控制：通過 Cluster Proportional Autoscaler，我們可以設定具體的比例規則，如每多少個節點增加一個副本，而不是依賴於默認的自動調整行為。
自定義策略：允許根據不同資源（如 CPU、內存）的使用情況設置不同的縮放策略，以滿足具體的運行需求。
避免過度配置：在大多數情況下，默認的自動調整行為可能會過度分配資源，而通過 Cluster Proportional Autoscaler 可以避免這種情況，實現更精細的資源管理。

Cluster Proportional Autoscaler 與 VPA 一樣，不是 Kubernetes 核心項目的一部分，它在 GitHub 上有自己的項目。